Aller au contenu principal

Contrôle MQTT programmé

astuce

Le contrôle MQTT planifié est destiné aux messages programmés à l'avance. Pour le contrôle en direct, consultez Contrôle MQTT en direct à la place.

Ce guide vous aidera à configurer MQTT sur votre SmartgridOne Controller pour contrôler et surveiller à distance les installations de batteries et de panneaux solaires.

Ce dont vous avez besoin

  1. SmartgridOne Controller avec connectivité Internet.
  2. Identifiants MQTT : Cela peut être demandé en envoyant un e-mail à support@eniris.be.
  3. Environnement de développement Python (ou tout autre client MQTT). Ce guide utilise un exemple de base écrit en Python pour vous aider à démarrer avec MQTT et l'envoi de commandes. Nous recommandons d'utiliser Python pour sa facilité d'utilisation, mais tout autre client MQTT est supporté.

Informations supplémentaires

MQTT est un protocole de communication rapide sur Internet. C'est un système de messages de publication/abonnement, qui permet une connexion directe entre votre machine et le SmartgridOne Controller. Vos actifs sont classés en groupes solaires, batteries, VE et CVC. Pour le moment, cette intégration permet un contrôle par groupe, pas par appareil.

Configuration initiale (Point de départ pour les nouveaux utilisateurs)

J'ai un SmartgridOne Controller que j'aimerais configurer pour le contrôle à distance par MQTT.

1. Vérifiez votre réseau

Assurez-vous que votre réseau autorise le trafic réseau MQTT sur le port 1883. Vous pouvez le faire en utilisant la commande :

nc -zv mqtt.eniris.be 1883

Lorsque cette commande n'est pas disponible, vous pouvez alternativement télécharger et exécuter ce code python.

En cas de doute, consultez votre ingénieur réseau ou utilisez temporairement le point d'accès 4G/5G de votre téléphone lorsque des erreurs de connexion se produisent.

remarque

Lorsque le port 1883 n'est pas accessible depuis votre réseau, nous proposons une alternative sur le port 80. Cela peut être configuré dans votre client MQTT à une étape ultérieure de ce manuel.

2. Ajoutez vos appareils

Connectez-vous à l'interface de mise en service et assurez-vous que les appareils sont ajoutés au SmartgridOne Controller.

3. Ajoutez le signal externe MQTT

Image 1
Image 1
Image 1

4. Activez le signal à distance MQTT

Sélectionnez tous les appareils que vous souhaitez inclure dans le contrôle à distance MQTT.

Image 1

5. Le signal à distance est ajouté

L'interface de contrôle à distance MQTT a maintenant été activée sur le SmartgridOne Controller.

Nous sommes désormais prêts à envoyer quelques commandes de base à l'aide d'un exemple simple. La colonne Statut vous indique si une commande est active.

Script de démonstration Python

Un bon point de départ serait de tester votre nouvelle intégration configurée avec un exemple simple.

Ce code de test effectue un travail simple en envoyant continuellement le calendrier suivant :

  • Batterie : Charger à 5 kW pendant 15 minutes dans 10 minutes
  • Solaire : Régler la puissance à 0 kW pendant une heure dans 30 minutes

Le SmartgridOne Controller répond avec un message d'accusé de réception contenant l'identifiant unique du calendrier, ou un message d'erreur.

Nous récupérons ensuite le prochain calendrier pour les deux types d'appareils, confirmant que la commande a réussi.

Veuillez télécharger le fichier ci-dessous dans votre IDE Python préféré. Remplissez votre numéro de série et vos identifiants MQTT et exécutez le script :

Lorsque cela est réussi, vous pouvez continuer à envoyer d'autres types de messages. Tous les messages sont décrits ci-dessous.

Documentation MQTT pour l'envoi de commandes

Cette section détaille le format de message MQTT et les exigences de charge utile pour configurer le contrôle programmé des appareils au sein du réseau du SmartgridOne Controller.

Sujets MQTT

  • Sujet d'abonnement : standard1/rp_one_s/remoteScheduleMetrics/<controller SN>
  • Sujet de retour d'information : standard1/outbound/remoteScheduleMetrics/feedback/<controller SN>

<controller SN> doit être remplacé par le numéro de série réel du SmartgridOne Controller que vous souhaitez contrôler.

Types de messages MQTT

1. Définir le calendrier (set_schedule)

Crée un nouveau calendrier pour un type d'appareil.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "set_schedule",
"fields": {
"device_type": "<Device Type>",
"node_id": "<Node ID>" (Optionnel),
"start_time": <Unix Timestamp>,
"end_time": <Unix Timestamp>,
"policy": "<Policy>",
"power_setpoint_w": <Setpoint en watts>,
"remove_overlap": <True/False> (Optionnel) (default=False),
"tag": <Tag String> (Optionnel) (default=None),
}
}

Réponse (Succès) :

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "set_schedule_ack",
"state": {
"schedule_id": <Schedule ID>,
"deleted_ids": <Schedulde IDs deleted if remove_overlap=True>
"tag": <Tag String> (default=None),
},
"responseCode": 0
}
}

2. Définir les calendriers (set_schedules)

Crée plusieurs nouveaux calendriers.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "set_schedules",
"fields":
"0": {
"device_type": "<Device Type>",
"node_id": "<Node ID>" (Optionnel),
"start_time": <Unix Timestamp>,
"end_time": <Unix Timestamp>,
"policy": "<Policy>",
"power_setpoint_w": <Setpoint en watts>,
"remove_overlap": <True/False> (Optionnel) (default=False),
},
"1": {
"device_type": "<Device Type>",
"node_id": "<Node ID>" (Optionnel),
"start_time": <Unix Timestamp>,
"end_time": <Unix Timestamp>,
"policy": "<Policy>",
"power_setpoint_w": <Setpoint en watts>,
"remove_overlap": <True/False> (Optionnel) (default=False),
},
...
}

Réponse (Succès) :

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "set_schedules_ack",
"state": {
"schedule_ids": <Schedule IDs>,
"deleted_ids": <Schedulde IDs deleted if remove_overlap=True>
},
"responseCode": 0
}
}

3. Obtenir le calendrier (get_schedule)

Récupère un calendrier spécifique par ID.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_schedule",
"fields": {
"id": <Schedule ID>
}
}

Réponse :

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_schedule_ack",
"state": <Schedule>,
"responseCode": 0
}
}

4. Obtenir le calendrier actif (get_active_schedule)

Récupère le calendrier actuellement actif pour un type d'appareil.

{
"extraTags": {
```json
{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_active_schedule",
"fields": {
"device_type": "<Device Type>",
"node_id": "<Node ID>" (Optionnel),
}
}

Response (Succès):

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_active_schedule_ack",
"state": <Schedule>,
"responseCode": 0
}
}

5. Obtenir le Prochain Horaire (get_next_schedule)

Récupère le prochain horaire à venir pour un type de dispositif.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_next_schedule",
"fields": {
"device_type": "<Device Type>",
"node_id": "<Node ID>" (Optionnel),
}
}

Response (Succès):

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_next_schedule_ack",
"state": <Schedule>,
"responseCode": 0
}
}

6. Obtenir les Horaires (get_schedules)

Récupère tous les horaires pour une date spécifique.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_schedules",
"fields": {
"date": "<Date String of Format dd/mm/yyyy>"
}
}

Response (Succès):

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_schedules_ack",
"state": {
"schedules": [<Schedule>, ...]
},
"responseCode": 0
}
}

7. Obtenir les Horaires Futurs (get_future_schedules)

Récupère tous les horaires futurs.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_future_schedules",
"fields": {}
}

Response (Succès):

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_future_schedules_ack",
"state": {
"schedules": [<Schedule>, ...]
},
"responseCode": 0
}
}

8. Supprimer un Horaire (remove_schedule)

Supprime un horaire spécifique par ID.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "remove_schedule",
"fields": {
"id": <Schedule ID>
}
}

Response (Succès):

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "remove_schedule_ack",
"state": "L'horaire <Schedule ID> a été supprimé avec succès",
"responseCode": 0
}
}

9. Obtenir les Retours du Site (get_feedback)

Récupère un retour détaillé sur l'état du système.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_feedback",
"fields": {
"device": <Device (node) level>
}
}

Response (Succès):

Structure de la Charge Utile de Retour d'Information

10. Topologie du Site (get_toplogy)

Obtenir la topologie du site.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_topology",
"fields": {}
}

Response (Succès):

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_topology_ack",
"state": {
"nodeId": <nodeId>,
"nodeType": <nodeType>,
"children": [{<ChildObject>}]
},
"responseCode": 0
}
}

Format de Réponse Standard des Horaires

{
"id": <Schedule ID>,
"device_type": "<Device Type>",
"node_id": "<Node ID>" (Optionnel),
"start_time": <Unix Timestamp>,
"end_time": <Unix Timestamp>,
"policy": "<Schedule Policy>",
"power_setpoint_w": <Setpoint en watts>,
"created_at": <Unix Timestamp>
}

Types de Composants et Politiques

Pour des détails sur les composants disponibles et les politiques qui peuvent être programmées, référez-vous à la section Composants et Politiques MQTT dans la documentation Live MQTT Control.

Les horaires spécifiques aux dispositifs peuvent être envoyés en utilisant le champ facultatif node_id, se référant à l'ID du nœud du dispositif contrôlable.

Gestion des Erreurs

Tous les messages peuvent renvoyer une réponse d'erreur avec responseCode: 1 lorsqu'une erreur se produit :

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "<Message Type>_ack",
"error": <Error Body>,
"responseCode": 1
}
}

Lorsqu'une erreur non liée se produit, le type de message sera (general_error).

Les erreurs courantes incluent :

  • Chevauchement d'horaire avec des horaires existants
  • Plage horaire invalide
  • Type de dispositif non trouvé
  • ID d'horaire non trouvé
  • Politique invalide pour le type de dispositif

Règles de Gestion des Horaires

  1. Règles de chevauchement
    • Les horaires ne peuvent pas se chevaucher pour le même type de dispositif
    • Les horaires ne peuvent pas se chevaucher pour le même dispositif
    • Les horaires pour le même dispositif et type de dispositif ne peuvent pas se chevaucher
    • Les horaires existants et se chevauchant seront supprimés si la variable remove_overlap est définie sur True lors de la création d'un nouvel horaire.
  2. Chaque horaire doit avoir :
    • Un type de dispositif valide
    • Une heure de début (timestamp Unix)
    • Une heure de fin (timestamp Unix)
    • Une politique (correspondant aux politiques disponibles pour le type de dispositif)
    • Un point de consigne de puissance (pour les politiques qui l'exigent)
  3. L'heure de début doit être avant l'heure de fin
  4. Si l'heure de début est dans le passé, elle est automatiquement changée pour commencer maintenant
  5. Les horaires ne peuvent être supprimés s'ils n'ont pas encore commencé. Les horaires actifs ne peuvent pas être supprimés.
  6. Les horaires peuvent être définis pour différents types de dispositifs indépendamment
  7. Le système applique automatiquement la politique appropriée lorsqu'un horaire devient actif